@isaacroldan this fixes the issue mentioned here. There was a regression where we were getting updates even when the assets fail to build because we were serving them from the .dev-bundle which gets freshly created even when the build fails but it should be using the local assets. When the build fails the old local assets should not be deleted and we should not get a new update event in the websocket

Nope, never mind. I double checked and it still sends an update event, something else is going on

Previously this was looking at copied files which broke when including assets for the adminspecificaiton after I fixed the issue where files were getting a new name on every build in dev even when there was no collision.

Fixed this to match copy-by-pattern.ts by looking at the source files, not the files in the destination folder.

Same here, fixed this to match copy-by-pattern.ts by looking at the source files, not the files in the destination folder.

Shouldn't generatesAssetsManifest be part of the config ?

you can safely change this from LifecycleStep to BundleUIStep
So you don't need to check at runtime for the config fields.

I think this should have a more explicit name?
The name suggests an in memory merge, but it is updating the existing file (or creating it if doesn't exist).

createOrUpdateManifestFilemaybe?

(Ref Line 96) 🐛 Bug: All three analysis passes flagged this: buildUIExtension now writes the main bundle to localOutputPath (the extension's own directory), but secondary assets at line 96 still write to dirname(extension.outputPath). When called through buildForBundle (which both dev and deploy use), extension.outputPath is mutated to the bundle directory. This creates a split:

1. Main bundle → written to local dir
2. should_render → written to bundle dir
3. executeBundleUIStep copies local dir → bundle dir (only main transfers)
4. Dev middleware checks local dir then source dir — should_render is in neither

This is entangled with the middleware change at middlewares.ts:83, which no longer falls back to the bundle directory. Fixing this line so all assets go to the local directory would make the middleware change correct. Without this fix, secondary compiled assets will 404 from the dev server.

Suggestion: Build secondary assets to the local directory, consistent with main:

🐛 Bug: All three analysis passes agree (confidence 0.90): formatBundleSize(extension.outputPath) reads from the bundle directory, but the file was just written to localOutputPath. The copy to the bundle directory happens later in executeBundleUIStep. On the first build, the file doesn't exist at the bundle path yet, so formatBundleSize silently returns empty string (it catches errors). On rebuilds, it reads the previous build's file — reporting stale size data. No crash, but the build success message loses bundle size info.

Suggestion:

💡 Improvement: The check extensionPoints.every(ep => ep?.build_manifest) is all-or-nothing: if even one extension point doesn't have build_manifest, manifest generation is skipped for ALL extension points — including those that do have it. Currently this works because UIExtensionSchema always generates build_manifest for every extension point. But the guard would silently drop manifest entries if a future configuration omits build_manifest for some targets.

Suggestion: A filter would be more robust than an all-or-nothing check:

🐛 Bug: Same pattern as readBundleManifest above but with the opposite failure mode: readFile + JSON.parse at line 132-133 run without any error handling. If manifest.json is corrupted from a previous failed build, JSON.parse throws an unhandled error that crashes the build. Unlike readBundleManifest which silently swallows errors, this one lets them propagate — blocking all subsequent builds until the developer manually deletes the corrupted file.

Suggestion: Wrap in a try/catch that falls back to an empty manifest:

🎨 Code Style: The cast extensionPoint as unknown as NewExtensionPointSchemaType uses as unknown to bypass TypeScript's type checking entirely. Since DevNewExtensionPointSchema extends Omit<NewExtensionPointSchemaType, 'intents'>, the core fields already match. The as unknown escape hatch suppresses potentially useful type errors that would catch real incompatibilities if these types diverge.

Suggestion: Consider widening mapManifestAssetsToPayload's parameter type to accept DevNewExtensionPointSchema directly, or use a direct cast without the unknown intermediary.

💡 Improvement: The catch block catches all errors including JSON.parse failures from corrupted or partially-written manifest.json files. A readFile ENOENT (file doesn't exist) should return null — that's expected when no manifest has been generated yet. But a SyntaxError from JSON.parse means the file exists but is corrupted (e.g., partial write during a concurrent rebuild race), and silently returning null hides that problem. The developer would see missing assets with no explanation of why.

Suggestion: Distinguish file-not-found from parse errors:

🔒 Security: The new middleware fallback serves files from extension.directory (the developer's source) using assetPath from the router. A crafted request like /extensions/{id}/assets/../../.env could read arbitrary files from the project directory. getAppAssetsMiddleware in the same file (lines 144-147) already has proper path traversal validation using resolvePath and startsWith. The inconsistency is worth addressing — the previous middleware only served from the build output temp directory, which had narrower scope. Now that the source directory is exposed, the same protection pattern should apply. The blast radius is limited to the developer's own machine (local dev server), but it's a gap compared to the established pattern.

Suggestion: Add path traversal validation matching the existing pattern from getAppAssetsMiddleware: